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Abstract 

Pattern-matching programming is an example of a rule-based programming style developed in functional 
languages. This programming style is intensively used in dialects of ML but is restricted to algebraic 
data-types. 

This restriction limits the field of application. However, as shown by [9] at RULE'02, case-based function 
definitions can be extended to more general data structures called topological collections. We show in this 
paper that this extension retains the benefits of the typed discipline of the functional languages. More 
precisely, we show that topological collections and the rule-based definition of functions associated with 
them fit in a polytypic extension of mini-ML where type inference is still possible. 



1 Introduction 

Pattern-matching on algebraic data-types (ADT) allows the definition of functions 
by cases, a restricted form of rule based programming that is both relevant and pow- 
erful to specify function acting on ADTs. ML adopted a restricted form of pattern 
matching, where only the top-level structure of an ADT is matched against the pat- 
tern [15]. Examples of more expressive patterns are given, e.g., by the Mathematica 
language. However, both ML-like language or Mathematica are restricted to the 
handling of terms, that is, tree-shaped data structures (sets or multisets handled in 
Mathematica are represented by terms modulo associativity and commutativity) . 

In [9] and [8] a framework where pattern matching can be expressed uniformly 
on many different data structures is exhibited. They rely on the notion of topo- 
logical collection which embeds a neighborhood relation over its elements. The 
neighborhood relation enables the definition of a general notion of path (a sequen- 
tial specification of a sub-structure); a pattern is used to specify a path that selects 
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an arbitrary sub-collection to be substituted. This leads to a general functional 
language where the pattern matching is not limited to ADTs. 

We show in this paper that the topological collections bring a smooth extension 
of the Hindley-Milner type system [10] [14] with some polytypism [12] and we suggest 
an extension of the Damas-Milner type inference algorithm that allows to find a type 
to programs expressed in an extension of mini-ML with topological collections and 
rule based transformations over them. 

Section 2 gives a brief description of the topological collections and their trans- 
formation; section 3 gives an overview of types in this framework; the types are 
investigated in section 4 where the typing rules and the inference algorithm are 
given; several direct extensions of the language are discussed in section 5 and sec- 
tion 6 concludes this paper. 

2 Topological Collections and Transformations 

Topological collections are data structures corresponding conceptually to a mapping 
from a set of positions into a set of values such that there is a neighborhood relation 
over the positions. Two values of a collection are said to be neighbors if their 
positions are neighbors. The sequence is an example of topological collection where 
the elements have at most a left neighbor and a right neighbor. The NEWS grid 
which is a generalization of arrays of dimension 2 is another example where each 
element has at most four neighbors, considering a Von Neumann neighborhood [13]. 

The notion of neighborhood is a means to embed in the programming language 
the spatial locality of computations of programs. 

Many other data structures can be seen from the topological point of view. For 
example the set and the multi-set (or bag) are topological collections where each 
element is neighbor of each other element (the set of positions of a set, is the set of 
the elements itself). See [7] for other examples of topological collections. 

These data structures come with a rule based style of programming: a rule de- 
fines a local transformation by specifying some elements to be matched and the 
corresponding action. The topological disposition of the matched elements is ex- 
pressed directly within the pattern of the rule. Thus a collection can be transformed 
by the simultaneous application of local transformations to non-intersecting match- 
ing sub-sets of the collection. 

The MGS programming language described in [7] and [8] supplies the topological 
collections as first-class values and transformations as a means to describe rule based 
functions over collections. The language we work on in our paper is largely inspired 
by MGS although some features such as the possibility for a collection to contain 
elements of different types have been left out. 

In the rest of this section we describe the handling of collections via rules in our 
restriction of MGS. 

A rule is written p=>e where p is the pattern and e is the expression that will 
replace the instances of p. A transformation is a list of rules introduced by the 
keyword trans. The application of a transformation trans [pi=>ei; P2 => e2~\ to a 
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collection c consists in selecting a number of non-intersecting occurrences of pi in c 
such that there is no further possible occurrence; then replacing the selected parts 
by the appropriate elements calculated from e±; then selecting a number of non- 
intersecting occurrences of P2 and replacing them with the appropriate values. 

The pattern can be a single element x or a single element satisfying a condition 
x/e where e is a boolean expression; it can also be a two elements pattern x, y such 
that y is a neighbor of x. Here the comma expresses the neighborhood relation and 
is not intended to express a tuple. The pattern xj(x = 0),y/(y = l),z/(z = 2) 
matches three values such that the first is a 0, the second is a 1, the third is a 2, 
the second is in the neighborhood of the first and the third is in the neighborhood 
of the second. 

The right hand side of the rule is composed of an expression denoting the ele- 
ments replacing the selected elements. In order to allow the replacement of parts 
by parts of different size, the value expressed in the right hand side of a rule must 
be a sequence. The elements of this sequence will substitute the matched elements. 
Thus we can consider rules replacing sub-parts constituted of a single element with 
several element, or sub-parts constituted of several elements with one element or 
even with no element, and so on. 

A way of building a sequence is using the empty sequence empty_seq and the 
constructor : :. The syntactic shortcut [e] can be used to express e: :empty_seq. 

2.1 Two examples 

The following two examples show two programs acting respectively on sequences 
and sets. 

Sorting a Sequence. 

A kind of bubble-sort is immediate: 

trans [ x, y/(y<x) => y : : x :: empty_seq ; x => [x] ] 

This two rules transformation has to be applied on the sequence until a fixpoint 
is reached. The fixpoint is a sorted sequence. 

This is not really the bubble-sort because the swapping of elements can happen 
at arbitrary places; hence an out-of-order element does not necessarily bubble to 
the top in the characteristic way. 

We will see in section 4 that the rule x => [x] is required. 

Eratosthene's Sieve on a Set. 

The idea is to apply the transformation on the set of the integers between 2 
and n. The transformation replaces an x and an y such that x divides y by x. 
The iteration until a fixpoint of this transformation results in the set of the prime 
integers less than n. 

trans [ x, y/(y mod x = 0) => [x] ; x => [x] ] 
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3 Typing the Collections and the Transformations 

The type of a topological collection is described by two pieces of information: the 
type of the elements inside the collection and its organization. The former is called 
its content type and the latter its topology (see [11] for an example of separation 
between the shape and the data). For example, a set of integers and a set of strings 
do not have the same content type but have the same topology. Collection types 
will be denoted by [r]p where r is the content type and p is the topology. Thus a 
set of strings will have the type [string] set. 

The usual notion of polymorphism of ML languages is provided on the content 
type. For example the cardinal function that returns the number of elements of 
a set would have the type [a] set — > int where a is a free type variable since it 
can be applied to a set irrespectively of the type of its elements. The nature of 
the content type does not affect the behavior of the cardinal function, therefore the 
polymorphism is said to be uniform on the content type. 

Instead of providing different functions that count the number of elements for 
each topology, the language provides the function size with the type [a]6 — > int 
where 9 is a free topology variable. Functions that accept any kind of topology are 
said to be polytypic [12]. 

A way of handling collections is using polytypic operators and constant collec- 
tions: the constructor operator : : has the type a — > [a]9 — ► [a]0; the destructors 
oneof and rest have the type [a]9 — ■> a and [a]6 — > [a]0 and are such that for any 
collection c, oneof (c) and rest(c) make a partition of c (see [3]). 

The constant collections are empty_set, empty_seq and so on. 

Collections can also be handled with transformations. As seen in the previous 
section, transformations are functions on collections described by rewriting rules. 
This kind of function is introduced by the keyword trans. For example the function 
trans [ x=> [x] ] implements the identity over collections and has the type [a]9 — > 
[a]6. It is the identity because it maps the identity to all the elements of the 
collection. 

As we said, the right hand side of a rule must be a sequence because the pattern 
matched can be replaced by a different number of elements. On some topologies 
such as the grid, the pattern and the replacement sequence must have the same 
size. If the sizes are not compatible a structural error will be raised at execution 
time. These structural errors are not captured by our type system. See [7] for more 
details on the substitution process in the collections. 

The map function can be expressed as follows: 

fun f -> trans [ x => [fx] ] 

and has the type (a — > (3) — > [a]0 — ► \fl]9. 

Unlike in the original MGS language, a collection cannot contain elements of 
different types. We have chosen to set this restriction to allow to build an inference 
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Fig. 1. Syntax of the language 



algorithm in the Damas-Milner style [5]. Allowing such heterogeneous collections 
would lead to a system with subsumption and union types that would need complex 
techniques to determine the types of a program. 



4 The Language 

In this section we first describe the syntax of the studied language. Then we describe 
the type verification rules and finally we give the type inference algorithm that 
computes the principal type of a program. 



4-1 Syntax 

Topological collections are values manipulated with constants, operators, functions 
and transformations, no new syntactic construction is needed. 

For the transformation we have to enrich the syntax of mini-ML [4] as shown in 
figure 1. 

The construction p => e is called a rule and a transformation is a syntactic list 
of rules. In the construction id/e occurring in a pattern, e is called a guard. 

The last rule of a transformation must be a variable for exhaustiveness purpose. 
Putting the rule x => [x] in last position of a transformation expresses that all 
unmatched values are left unmodified. It is not possible to infer a relevant default 
case for a transformation. For example the rule x => [x] cannot be the default case 
for a transformation of the type [string]9 — > [int]9. Therefore the default case must 
be specified explicitly by the programmer. This explains the grammar for the list of 
rules I which enforces the presence of a last rule of the form id => e matching every 
remaining element. The expression e in the right hand side provides the appropriate 
default value. 

We will use some operators such as : : in an infix position but this syntax can 
be easily transformed into the one of figure 1. Operators are functional constants 
of the language. 
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4-2 The Type System 
Types Algebra 

We enrich the polymorphic type system of mini- ML with the topological collections. 
The collection type introduces a new kind of construction in types: the topology. 

From a type point of view, transformations are just functions that act on topo- 
logical collections without changing their topology, so no new construct is needed 
for them in the type algebra. 

Types : r ::= T base type (int, float, bool, string) 

a type variables 

t — > t functions 

txt tuples 

[t]p collections 



Topologies : p ::= R base topology (bag, set, seq, grid, ...) 

topology variables 

We give in appendix A the definitions of Ct and C r which calculate the type 
variables and the topology variables occurring in a type. 

Type Schemes 

A type scheme is a type quantified over some type variables and some topology 
variables: 

a ::= V[ai, . . . ,a n ][0i, . . . ,9 m ].T 

A type r is an instance of a type scheme a = V[«i, . . . , a n ][6*i, . . . , 9 m ].T' and 
we write cr < r if and only if there are some types 7~i, . . . ,r n and some topologies 
pi,...,p m such that r = r'[ai <- n, . . . , a n <- r n , 9\ <- pi, . . . , 9 m <- p m ] . 

In the following, an environment is a function from identifiers to type schemes. 

TC is the function that gives the type scheme of the constants of the language. 
For example TC{: :) is V[a][#].a — > [a]6 — > [a]9. 

Ct and C r are extended to type schemes and calculate the free variables of a type 
scheme, that is the variables occurring in the type scheme which are not bound by 
the quantifier. For example if a is V[ai] [#i].[ai]#i — > [0:2)^2 then £t(<r) is a.2 and 
£ r (cr) is 62- 

Typing Rules 

The typing rules are nearly the same as the Hindley-Milner rules [10] [14]. The 
differences are that a rule has been added for the transformations and that the 
notions of instance and the Gen function have been adapted to the type algebra. 

The Gen function transforms a type into a type scheme by quantifying the 
variables that are free in the type and that are not bound in the current environment. 
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The definition of Gen is the following: 

Gen(r,T) = V[ai, . . . ,a n ][9x, . . . ,9 m ].T with {ai, . . . ,a n } = £f(r)\£ t (r) and 
{9 1 ,...,e m } = £ r (T)\C r (T). 

The typing rules are: 

T(x) < t TC(c) < T 

— (var — inst) — — (const — inst) 

T \- x : t T \- c : t 



ru{x:n}l-e:Ta f£ r h ei : t' > t Y h e 2 : r' 

(/™) — (app) 



T h (fun x — > e) : ri — > r 2 r h ei e 2 : r 

r h ei : ri T U {x : Gen(ri, T)} h e 2 : T"2 



(Zet) 

1 r (let x = e\ m e2j : t 2 

{r U {4 : r} u < mi) U {self : [r]p} h e, : [r']se 9 } ( ,< n) 
{ruK :r} (j < fc) U{self : [r]p} h e^: bool} 
Th trans [x\/e\ x'™ 1 /e^ 1 =>ei ; ... ;xi / e i , ... /e™" =>e n ] : [ r ]p ^ [r']p V ; 

In the (trans) rule, k n is always equal to 1 and is always equal to true. 
Inside a rule the self identifier refers to the collection the transformation is 
applied on. 

The (trans) rule expresses that a transformation has the type [r]p — > [r']p if 
when you suppose that all the x\ have the same type r and that self has the type 
[r]p it can be proven that the e\ are boolean values and that the ej have the type 
[r'jseg. 

We can see that if self is not used in a transformation, this one will be polytypic 
since p will not be bound to any topology. 

The following examples show a type verification on a polytypic transformation 
and on a non-polytypic one. 

Polytypic Example 

The following transformation can be proven to be an [int]8 — > [int]8 function for 
any topology 9. 

trans [ x, y/x>y => x : : y : : (x-y) : : empty_seq ; x => [x] ] 

The proof is given in figure 2a where To = {x : int; y : int;self : [int]0}, 
Ti = {x : int; self : [int]9} and with the following lemmas: 

r h e\ : int T h e 2 : [int]seq T h e : r 



r h ei : :e 2 : [int]seg r h [e] : [r]seg 

Non-Polytypic Example 

The operator is_left acts as a predicate that returns true if the element is at 
the left extremity of the sequence. Thus it returns false is the element has a left 
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r (x)<int ... T 1 (x)<int 

T \- x : int T h y : : (x-y) : : empty_seq : [int]seq T\ h x : ini 
To h x>y : 600/ To H x: :y: : (x-y) : :empty_seq : [int]seq T± h [x] : [mijseg 

h trans [ x,y/x>y => x: :y: : (x-y) : :empty_seq ; x=> [x] ] : [int]0 — > [int]6 



TC (not) < bool — > bool ... ... T 2 {x) < int 

T2 h not : 600/ — > 600/ T2 h not(is_left x self) : bool T2 \~ x+(left x self) : int T2 \~ x : int 

T2 h not (is_lef t x self) : 600/ T2 h [x+(left x self)] : [int]seq T2 h [x] : [mijseg 

h trans [ x/ (not (is_lef t x self ))=> [x+ (left x self)] ; x=> [x] ] : [int]seq — > [int]seq 

GO 
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neighbor. It can be used only within a transformation 2 and takes two arguments: 
the first is a pattern variable and the second is a collection. Similarly, the operator 
left takes a pattern variable x and a sequence s and returns the left neighbor of x 
in s. 

Let us consider the following transformation: 

trans [ x/ (not (is_left x self)) => [x+(left x self)] ; x=> [x] ] 

This transformation does not have the same effect as the following one: 

trans [1, x => (1 :: 1+x :: empty_seq) ; x=> [x] ] 

because in the former, every element x of the sequence except the leftmost one will 
be replaced by the sum of itself and its left neighbor whereas in the latter, the I 
element will be replaced by itself and thus will not be increased. For example the 
former transformation applied to the sequence (1: :2: :3: :4: remptyjseq) results 
in (1::3::5::7: :empty_seq) whereas the application of the latter transformation 
to the same sequence would result in ( 1 : : 4 : : 3 : : 7 : : emty_seq) . 

The figure 2b where T2 = {x : int; self : [int]seq} proves that the first transfor- 
mation has the type [int]seq — ► [int]seq. 

This transformation cannot be proven to have the type [inijp — ► [int]p if p ^ seq 
because left and is_left act exclusively on sequences. 

4-3 Type Inference 

The typing rules given in section 4.2 are a means to verify that a program has a 
given type but this type is a parameter of the verification procedure. We now give 
the equivalent of the Damas-Milner type inference that enables the full automated 
type verification since it computes the principal type of a program. The resulting 
type is said to be principal because every type that can fit the program is an instance 
of this type. 

The type inference algorithm is given after the unification procedure. 
Unification 

Unifying two types T\ and T2 consists in finding a substitution ip over the free 
variables of t\ and T2 called the unifier such that ip{j\) = ip(Ti). 

A substitution is a most general unifier (mgu) for two types t\ and T2 if for any 
unifier <p>\ of t\ and T2, there is a substitution (p% such that tp = (p% ° (pi- 

We give the mgu function that computes the most general unifier of a set of 
pairs of types denoted by t\ = t<i. This function is necessary to the type inference 
procedure. If mgu fails then there is no unifier for the given types. 

The difference between our mgu and Damas and Milner's original mgu is the 
addition of the case for the collection types. Two collection types are unified by 
unifying their content types and their topologies. The substitution doing this unifi- 



2 The is_lef t operator is only available in transformations, where the identifiers introduced by the pattern 
are bound to a position in the collection. Allowing only such identifiers to be arguments of is_lef t allows 
to remove any ambiguity on the position denoted in the sequence, even if the position contains a value 
occurring several times. 
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cation is found as (pi o ip 2 where <p 2 unifies the topologies and ipi unifies the content 
types. The computation of (/3 2 is made by the dedicated mgu r function. This func- 
tion fails when the two topologies are different base topologies since they cannot be 
unified. The substitution <p 2 is applied to the content types before computing ipi 
with mgu. 

The standard cases of the definition of mgu are: 

mgu(0) = [] 

mgu({r = r} U C) = mgu(C) 

mgu({a = r} U C) (if a is not free in r) = let <p = [a «- r] in mgu.(<p(C)) o ip 

mgu({r = a} U C) (if a is not free in r) = let ip = [a <- r] in mgu(<p(C)) o ip 

mgu({n -» r 2 = t[ -> r^} U C) = mgu({n = r'l ; r 2 = r'2} U C) 

mgu({Ti x r 2 = r( x r^} U C) = mgu({Ti = r'l ; r 2 = r'2} U C) 
The new case for the collections is: 

m gu({[ T ]p = \ t ']p'} u C) = let = mgu r (/9 = p') in mgu(f/?({r = r'} UC)) o 
The unification of topologies is defined by: 

mgu r (p = p) = [] 
mgu r (6» = p) = [6<- p] 
mgu r (p = 9) = [O^p] 



Type Inference 

The type reconstruction algorithm is nearly the same as the Damas-Milner one. The 
differences are that it uses specialized versions of mgu and Gen functions and that 
there is a new case for the transformations. It is described here in an imperative 
way: (p is the current substitution and Vt and V r are sets of free type variables and 
topology variables. 

The algorithm is given in figure 3. 

The case for the transformations consists in unifying the types of all the pattern 
variables and unifying the types of the right hand side rules together and with a 
sequence collection type. These unifications have to be made with respect to the 
guards that are boolean values. 

If W succeeds it computes the most general type of the program analyzed and 
this one can be run without type error. If it fails because of an mgu or an mgu r 
failure then the program is ill-typed and might lead to a type error at execution 
time. 
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f resh_t = let a G Vt 

do Vt <- V t \{a} 
return a 

f resh_r = let 9 6 V r 

do V r *- V r \{9} 
return 9 

W(T h e) = 

(* original cases *) 

fet V[cti, . . . , Q„][6»i, m ].r = 1» 

let a^, . . . , ct' n = f resh_t, . . . , f resh_t 

let 0^, ... , 9' m = f resh_r, . . . , f resh_r 

return r[ai «- a[, . . . ,a n <- a4,0i <- 0^, . . . , 0m «- 9' m ] 
If e = fun x — > e 

let a = fresh_t 

let r = WfUi : V[][].a h e) 

return o — > r 
If e = ei e2 

let ri = W(r h ei) 

let r 2 = w(r h e 2 ) 

let a = fresh_t 

do ip <- mgu(^(n) = i/3(r2 — + a)) o <p 
If e = let x = ei in e2 
let n = W(T h ei) 
let ct = Gen(<p(-n), ip(T)) 
return W(r U {x : <r} h e 2 ) 



(* new case for the transformations *) 
If e = trans [pi=>ei; p„=>e„] 

let a,f3 = f resh_t, f resh_t 

let = fresh_r 

for % = l..n 

let irf^ /e 1 , . . . , id m * /e m ' = p; 

for j = 1..771; 

let r| = W(r U {self : [a]0} U {idf : a} k <j h e^) 

do <- mgu({i/>(T l J ) = feooi}) o i/3 
let n = W(T U {self : [a}9} U : a} k < mi \~ ei) 
do 95 <- mgu({i y 3(Ti) = ¥>([/3]seq)}) o 95 
return [a]0 -> [/3]0 



Fig. 3. Type inference algorithm 

5 Extensions 



5.1 Repetition in a Pattern 

The star * expressing an arbitrary repetition of a sub-pattern during the matching 
process has been introduced in [9]. The pattern x/ (x=0) , * as y, z/(z=0) for 
example can match an arbitrary subcollection such that it contains two and that 
there is a path between these 0. This means that one can reach the second from 
the first one only by going from an element to one of its neighbors repetitively. 
To take the star into account we modify the syntax of the patterns as follows: 



p ::= q | q,p 

q ::= id | * as id 

where q stands for elementary patterns. 

We have not kept the guards in the elementary patterns in order to keep the 
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formulas readable but their addition does not lead to new problems. 

The elements matched by the star are named and can be referred to as a se- 
quence. 

The star could have been considered as a repetition of a subpattern as in 
(x,y/x=y)* but we have chosen to restrict the star to the repetition of single ele- 
ments for the sake of simplicity. 

Before giving the new typing rule, we introduce a function which gives the type 
binding corresponding to an elementary pattern: b(q, r) is such that b(x, t) = (x : r) 
and 6(* as x, r) = (x : [r]seq). This function is used in the trans typing rule which 
is modified as follows: 



{T U W^t)}^ U {self : [r\p} h : [rjseq}^ 
r h trans [q\ , ... , q\ x =>e\ ; ... ;q} l , ... , qn n =>e n 1 : [r)p — > [r']p 



(trans') 



5.2 Directions in Patterns 

In section 4.2 we saw the operator left that returns the left neighbor of an element 
in a sequence. In the framework of topological collections, a topology can supply 
several neighborhood operators. For example left and right are the neighborhood 
operators of the sequence and north and east are neighborhood operators of the 
grid. Neighborhood operators are also called directions. 

A direction can be used to refine the patterns: the commas of the pattern can 
be substituted by a direction to restrict the accepted neighbors for the rest of the 
pattern. The substituting direction is surrounded with the symbols I and > to 
sketch a kind of arrow. 

For example if d is a direction we can use the pattern x I d> y which is a short- 
cut 3 for x,y/y=(d x self). However, the pattern x |d> y allows faster research 
of the instances of the pattern in the collection than x,y/y=(d x self). 

The pattern x |d> y can be typed as x,y/y=(d x self). 



The Bead-Sort Example 

The bead-sort is an original way of sorting positive integers presented by [2] . The 
sorting algorithm considers a column of numbers written in unary basis. Figure 4a 
shows the numbers 3, 2, 4 and 2 where the beads stand for the digits. The sorting 
is done by letting the beads fall down as shown on figure 4b. 

The problem can be represented on a grid of booleans where true stands for 
a digit and false for the absence of digit as shown on figure 4c. The bead-sort is 
achieved by iterating the application of the following transformation until a fixpoint 
is reached: 

trans [ x/x=false |north> y/y=true => y: :x: :empty_seq ; x=> [x] ] 

The first rule of this transformation is expressed as 

3 The expression y=(d x self) in a guard where y is a pattern variable and d is a direction tests that the 
values denoted are the same and that their positions in the collection are the same. See the MGS manual [6] 
for more details. 
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(3) 
(2) 
(4) 
(2) 



(2) 
(2) 
(3) 
(4) 



(a) 



(b) 



t t t f 

t t f f 

t t t t 

t t f f 

(c) 



Fig. 4. The Bead-Sort 



t t f f 

t t f f 

t t t f 

t t t t 

(d) 



x/x=false , y/(y=true && y=north x self) => y : : x : : empty_seq 

in order to fit the type system. The result of W on this transformation is [bool]grid 
[bool]grid. 



5. 3 Strategies 

As far as the rules application strategy guarantees that every element of the collec- 
tion is matched (this is always possible since the last rule always matches) the type 
system is not affected. 

For instance, the MGS language provides several strategies such as higher pri- 
ority given to the first rules or random application of the rules. 



6 Conclusion 

Including the topological collections and pattern matching programming on these 
structures in the ML framework allows to bring together a powerful programming 
language with a rule programming framework common to several other languages. 

Our algorithm has been tested on MGS programs and has been included in a 
prototype MGS compiler in order to achieve type-oriented optimizations on the pro- 
duced code. We believe that the best pattern matching algorithms would be wasted 
on a dynamically typed language and thus a type inference algorithm is an impor- 
tant step in the development of an efficient compiler for rule based transformations. 

However some restrictions on the MGS language had to be done in order to 
keep the simplicity of the Damas-Milner algorithm. We are currently working on a 
type inference system with union types [1] to account for heterogeneous collections 
supplied by the MGS language. 

Finally, we said that an error could occur when a transformation tries to replace 
a subpart by a part of different shape on topologies as the grid which cannot get 
out of shape. Such errors are not type errors but some of them could be detected 
statically with a specific type based analysis. Some research such as [11] manage 
with this kind of error but the concerned languages do not provide the flexibility of 
the rule based transformations proposed here. 



A Free Variables 

The free variables of a type are the variables occurring in that type. Ct computes 
the free type variables whereas C r computes the free topology variables. 
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Cohen 



Ct(T) = 

C t (a) = {a} 

Ct(n^r 2 ) = Ct(n)uC t (r 2 ) 

C t (T 1 xr 2 ) = A(ri) U C t (r 2 ) 

C t ([r]p) = C t (r) 



C r {T) = 

C r (a) = 

£ r (n -> r 2 ) = £ r (ri) U £ r (r 2 ) 

£ r (riXT 2 ) = £ r (ri) U £ r (r 2 ) 

A-([r]0) = {e}UC r (r) 



C r ([r]R) = C r (r) 
The free variables of a type scheme are the non-quantified variables occurring 
in it: 

£i(V[ai, . . .,a n ], [6»i, . . . ,0 m ].r) = £ t (r)\{cti,. . . ,a n } 
£ r (V[ai, . . .,a n ], [6i, . . . ,0 m ].r) = C r (r)\{0i, . . .,0 m } 
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